If I understand the error message in the failing tests correctly -- and I'm not sure I do -- then there can only be one constructor available to DI whose first argument is CallInvoker. I think we can work around this by marking the added constructor with [ActivatorUtilitiesConstructor], but this then also requires that we have a dependency on the Microsoft.Extensions.DependencyInjection.Abstractions package which would be unfortunate. I am not a user of Flight (or more broadly of Grpc) so I don't know what the tradeoffs here are.

I'm also not super keen on dependency injection :(.

Updated per review feedback:

• Replaced ICompressionCodecFactory with ArrowContext across all Flight record batch readers
• ArrowContext carries compression codec factory, memory allocator, and extension type registry
• Used optional parameters (ArrowContext context = null) instead of constructor overloads — this avoids the DI ambiguity with multiple CallInvoker constructors, no need for [ActivatorUtilitiesConstructor] or extra dependencies
• All existing code works unchanged (context defaults to null)

Usage:
var context = new ArrowContext(compressionCodecFactory: new CompressionCodecFactory());
var client = new FlightClient(grpcChannel, context);

Updated with tests and fixes:

• 4 new tests added (55 total, all passing):
  • TestGetWithArrowContext — verify Get works with ArrowContext
  • TestGetWithNullArrowContext — backward compat with null context
  • TestPutAndGetWithArrowContext — put+get round-trip with context
  • TestFlightClientDefaultConstructorStillWorks — original constructor unchanged
• Fixed pre-existing netstandard2.1 build error in CookieExtensions.cs (collection expression syntax ambiguous with Split overloads)

I've been testing this end-to-end with our production Arrow Flight server (EnergyScope — energy market data). With lz4 compression enabled, we see a 3.5x improvement on large queries (1.45M rows: 45s → 13s)
through our C# Excel add-in.

For binary backwards compatibility, can you instead add a second public constructor with the additional parameter? i.e.

public FlightServerRecordBatchStreamReader(IAsyncStreamReader<FlightData> flightDataStream)
    : this(flightDataStream, null)
{
}

public FlightServerRecordBatchStreamReader(IAsyncStreamReader<FlightData> flightDataStream, ArrowContext context)
    : base(new StreamReader<FlightData, Protocol.FlightData>(flightDataStream, data => data.ToProtocol()), context)
{
}

For binary backwards compatibility, can you instead add a second public constructor with the additional parameter? i.e.

public FlightClient(ChannelBase grpcChannel) : this(grpcChannel. null)
{
}

public FlightClient(ChannelBase grpcChannel, ArrowContext context)
{
    _client = new FlightService.FlightServiceClient(grpcChannel);
    _context = context;
}

For binary backwards compatibility, can you instead add a second constructor with the additional parameter? This one is trickier because the DI mechanism doesn't like having two constructors that both match what it's looking for, so we need to use a factory method instead:

public FlightClient(CallInvoker callInvoker) : this(callInvoker. null)
{
}

private FlightClient(CallInvoker callInvoker, ArrowContext context)
{
    _client = new FlightService.FlightServiceClient(callInvoker);
    _context = context;
}

public static FlightClient Create(CallInvoker callInvoker, ArrowContext context)
{
    return new FlightClient(callInvoker, context);
}

It would then also be good to add a test which exercises this code path. You could clone the existing TestIntegrationWithGrpcNetClientFactory test and then replace the client setup with

services.AddGrpcClient<FlightClient>(grpc => grpc.Address = new Uri(_testWebFactory.GetAddress()))
    .ConfigureGrpcClientCreator(invoker =>
{
    return FlightClient.Create(invoker, new ArrowContext());
});

This will also demonstrate to users how to use an ArrowContext with the factory.

I don't specifically have a preference for the newer collection syntax, but I don't see any reason to change it to the older one.